REMARKS 

Claims 1-45 remain pending in the application. Reconsideration is respectfully 
requested in light of the following remarks. 

Section 102(e) Rejection : 

The Office Action rejected claims 1-3, 5, 6, 16-18, 20, 21, 31-33, 35 and 36 under 
35 U.S.C. § 102(e) as being anticipated by Carre (U.S. Patent 6,282,579). Applicants 
respectfully traverse this rejection for at least the following reasons. 

Regarding claim 1, applicants disagree with the Examiner's interpretation of 
Carre and assert that Carre does not teach a gateway configured to deliver messages 
between managed objects and one or more managers through a platform-independent 
interface, wherein the gateway is configurable to deliver the messages for each manager 
in a format selected by that manager , as the examiner contends. Carre pertains to address 
conversion between CORBA objects and OSI objects (Carre - col. 1, lines 9-19; col. 1, 
line 59 - col. 2, line 46) and to the transforming of object interfaces column 5, lines 49- 
59). Thus, Carre is concerned with converting address types and object interfaces, but 
fails to teach anything regarding message formats . 

Specifically, Carre teaches that address conversion is performed according to the 
type of objects that are communicating. There is no ability in Carre for the managers to 
select a desired message format. The sections cited by the Examiner (col. 5, lines 49-59 
and col. 6, lines 30-35) refer to address-type conversion between CORBA objects and 
OSI objects. There is absolutely no mention in Carre of managers being able to select the 
format for messages delivered by the gateway. Nor does Carre does not describe any 
mechanism by which a manager can select a format for messages. Carre fails to mention 
anything about different message formats. The gateway in Carre is clearly not capable of 
allowing the managers to select a format. 
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In response to Applicants' previous arguments, the Examiner states that 
appHcants fail to consider the teaching of Carre for delivery of messages through 
different interfaces (CDMO and CMISE) by gateways and cites Figures 3a and 3b. The 
Examiner contends that since Carre teaches more than one gateway and since they each 
communicate via different interface, they perform the same function as a gateway 
configurable to deliver messages for each manager in a format selected by that manager. 
Applicants respectfully disagree with the Examiner interpretation of Carre's interfaces. 
Specifically, Carre states that these interface units translate an interface to the underlying 
object so that the underlying object "can be access by class CORBA message" (Carre, 
column 5, lines 50-52). Carre also states that his CMISE/IDL interface "appears to the 
outside, like a CORBA object" (Carre, column 5, lines 26-31). One portion of Carre 
cited by the Examiner (column 5, lines 49-59) describes how OSI objects OM and OA 
can be transformed into pure CORBA objects to allow them to be accessed using classic 
CORBA messages . Thus, Carre is clearly teaching the transformation of object 
interfaces so that a single message format (classic CORBA) may be used with either OSI 
objects or CORBA objects. Furthermore, Carre's manager objects cannot select which 
interface to communicate through. On the contrary, Carre teaches that his interfaces are 
present to allow interaction between CORBA and OSI objects "via a CORBA 
infrastructure" (Carre, column 4, line 63 - column 5, line 3). Carre teaches the use of 
additional communication layers (GDMO/C++, GDMO/IDL and CMISE/IDL), or 
components, between OSI objects and CORBA objects that translate the interfaces to the 
objects such that they appear as and are accessible as CORBA objects using CORBA 
messages (Carre, Figures 2a and 2b, column 5, lines 49-59). In other words, Carre's 
interfaces are present specifically to provide communicate between otherwise 
incompatible objects. If one of Carre's managers were able to select a different interface, 
it would not be able to interact with the target object. 

Furthermore, Carre's interfaces are not message formats. Even if a manager in 
Carre could select a different interface, which Applicants assert they cannot, such a 
selection would still not be selecting a format for message deUvery as the Examiner 
contends. Object interfaces and message formats are different things. In Carre's 
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invention, different interfaces are provided specifically to allow different object types 
(specifically OSI or non-CORBA object) to access and send message through a single 
CORBA infrastructure. Carre's system is quite different from a gateway configured to 
deliver the message for each manager in a format selected by that manager. 

Carre specifically teaches the use of object interfaces and additional 
communication layers to allow heterogeneous (CORBA and OSI) objects to 
communicate via a single, homogeneous infrastructure (CORBA) rather than having a 
gateway configurable to deliver messages in a format selected by a manager. Thus, Carre 
is teaching awav from a gateway configured to deliver the message for each manager in a 
format selected by that manager. 

Applicants remind the Examiner that for a rejection under section 102, the 
identical invention must be shown in as complete detail as is contained in the claims. 
M.P.E.P. § 2131; see also, Richardson v. Suzuki Motor Co,, 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). Anticipation requires the presence in a single prior art reference disclosure of 
each and every element of the claimed invention, arranged as in the claim . Lindemann 
Maschinenfabrik GmbH v. American Hoist & Derrick Co,, 221 USPQ 481, 485 (Fed. Cir. 
1984). Carre does not disclose selected message formats, nor does Carre teach a gateway 
(or any other mechanism) through which a manager could make such a selection. Carre ^ 
therefore clearly does not anticipate a gateway is configurable to deliver the messages for 
each manager in a format selected by that manager. 

In light of the above remarks, applicants assert that the rejection of claim 1 is not 
supported by the cited art and withdrawal of the rejection is respectfiiUy requested. 
Similar remarks as discussed above in regard to claim 1 apply to claims 16 and 31. 

In regard to claim 2, Carre does not teach that the selected format comprises text. 
The Examiner cites column 6, lines 30-35 of Carre. However, this passage of Carre 
merely mentions the mapping of ASN.l onto IDL data types to allow translation of OSI 
address types to CORBA address types. Additionally, Carre is not discussing the 
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mapping of ASN.l to IDL data types or the translation of address types from OSI to 
CORBA in the context of a selected format for message delivery. Instead, Carre is 
talking about the translations necessary to allow OSI objects to communicate via 
CORBA. Further, Carre does not teach that such address translations involve a format 
that comprises text. 

In response to applicants' previous arguments, the Examiner contends that 
applicants have "failed to consider the teaching of Carre for sending the outcome 
message to the client based on what information [is] required by the client in [the] request 
message" and further argues that "[a]ll of these messages include context and [are] 
related to different target object[s]." However, Carre does not teach that a client is 
selecting a message format comprising text by including a request context in a request 
message. In fact, Carre fails to mention anything about message formats comprising text. 
Carre simply teaches that request messages can include: an operation, a target object, one 
or more parameters, and, optionally a request context. Clients including a request context 
in a request message, as taught in Carre, has nothing to do with a manager selecting a 
deliver format comprising text. Furthermore, Applicants' respectfully disagree with the 
Examiner interpretation that Carre's inclusion of a request context implies the selection 
of a format comprising text. Without a clear disclosure by Carre that including a request 
context in a request message is the equivalent of selecting a message format comprising 
text, such an interpretation is merely hindsight speculation on behalf of the Examiner. 

Thus, in light of the above remarks, applicants assert that the rejection of claim 2 
is not supported by the cited art and withdrawal of the rejection is respectfully requested. 
Similar remarks as discussed above in regard to claim 2 apply to claims 17 and 32. 

Claims 1, 2, 4-11, 13-17, 19-26, 28-32, 34-41 and 43-45 were rejected under 35 
U.S.C. § 102(e) as being anticipated by Shank et al. (U.S. Patent 6,445,776) (hereinafter 
"Shank"). Applicants respectfully traverse this rejection for at least the following 
reasons. 
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Regarding claim 1, Shank does not teach a network management system 
comprising a gateway configured to deliver messages between managed objects and one 
or more managers through a platform-independent interface, wherein the gateway is 
configurable to deliver the messages for each manager in a format selected by that 
manager , as stated by the Examiner. Instead, Shank pertains to providing telephony and 
media services from a server 110 to an appUcation 140 (Shank, Figure 1, column 1, lines 
13-18). Shank is not concerned with, nor does Shank pertain to managers and managed 
objects. According to Shank, a server may include various service interfaces, such as 
telephony services 210, media services 220, and basic services 230 that a chent may use. 
Shank's system provides a CORE A ORB 260 for communicating with these interfaces 
(col. 3, line 31 - col. 4, line 13). As described in Shank, the service interfaces (such as 
telephony services 210 and media services 220) allow client application 140 to interact 
with services such as telephone services provided on telephone network 105 and media 
services provided by various hardware components (col. 7, lines 15-28). 

Contrary to the Examiner's assertions, the service interfaces 210, 220 and 230 of 
Shank's server 110, do not provide a gateway configurable to deliver the messages for 
each manager in a format selected by that manager . Shank does not pertain to 
interactions between managers and managed objects as these entities are understood in 
the art. Instead, Shank only discusses the client-server interactions between application 
140 and server 110. In other words, Shank only discusses providing telephony and media 
services through a server to a client application. As discussed above, Shank's interfaces 
210, 220, 230 provide service interfaces for an application 140. They do not deliver 
messages between managed objects and one or more managers. Telephony service 
interface 210 is not a manager for managed objects. The concept of managers and 
managed objects, and the relationship between managers and managed objects, is well 
understood in the art of managed networks. In contrast, telephony service interface 210 
(including 212-216) is clearly described in Shank as providing an interface for 
appUcation 140 to access services on telephony network 105. Interfaces 210-216 in 
Shank have nothing to do with managing managed objects on a managed network. 
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Furthermore, Shank clearly does not teach a gateway that is configurable to 
deliver the messages for each manager in a format selected by that manager . The 
Examiner refers to col. 5, lines 39-50 and col. 17, lines 26-37. However, these portions 
of Shank merely give examples of media and telephony services accessible through 
Shank's interfaces 220 and 210. This portion of Shank has nothing to do with message 
formats, let alone delivering a message in a format selected by a manager. Applicants' 
fail to see any relevance of the Examiner's cited references. The Player, Recognizer, etc. 
discussed in Shank are media services, not managers for managed objects in a managed 
network. Moreover, there is clearly no teaching in Shank of a manager using these 
services to select a format for message delivery. 

Shank teaches that his service interfaces are defined according to the target object 
or target hardware, such as text-to-speech services 222, or facsimile services 228, and 
fails to teach that the formats of messages are selected by a manager managing such a 
target object. In fact, Shank teaches the use of a custom format "based on similar 
methods specified in the ECTF S 1.00 API," but defined using IDL (Shank, column 17, 
Unes 31-34). Data used by these interfaces is "in the form of a key value set (KVS) 
which contains a sequence of keys associated with values " and "[sjtructurally, a KVS is 
a sequence of key value pairs (KVPairs)" (Shank, column 9, lines 1-7). According to 
Shank, application 140, which the Examiner has erroneously characterized as a manager, 
communicates with various services using whatever interface the service has registered 
with resource administrator 236 (Shank, column 5, lines 16-22). Thus, Shank clearly 
teaches the use of predefined message formats and not the use of formats selectable by a 
manager. 

In response to Applicants' previous arguments, the Examiner responds that 
applicants have failed to consider the teaching of Shank "for providing services through 
media, telephony and basic services interfaces" and fiirther argues that Shank's interfaces 
perform message delivery function as a gateway. However, as described above, Shank's 
interfaces are defined according to the target object or target hardware, such as text-to- 
speech services 222, or facsimile services 228, and the formats of messages are not 
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selected by a manager managing such a target object. Furthermore, as with the rejection 
of claim 1 over Carre, the Examiner seems to be confusing interfaces with message 
formats. Different interfaces do not imply selectable delivery formats. Applicants 
further point out that the Examiner's cited portions of Shank (column 5, Hnes 39-50 and 
column 17, lines 26-37) teach only that different interfaces may include different method 
definitions, but fail to teach anything regarding the format of messages and further fail to 
teach message formats selectable by a manager. 

Thus, in Hght of the above remarks, applicants assert that the rejection of claim 1 
is not supported by the cited art and withdrawal of the rejection is respectfully requested. 
Similar remarks as discussed above in regard to claim 1 apply to claims 16 and 31. 

In regard to claim 2, Shank does not teach wherein the selected format comprises 
text, as expressed by the Examiner. The Examiner cites item 228 of Figure 2. However, 
item 228 refers to a FAX service, and it is well known that a facsimile interface does 
include text, but rather involves a graphic interface. AppUcants fail to see the relevance 
of item 228 of Figure 2 to a selected format that comprises text. 

In response to Applicants' previous arguments, the Examiner directs applicants to 
the teaching of Shank for providing text-to-speech services. The text-to-speech referred 
to by the Examiner are services accessed by client application 140. For example, the 
text-to-speech service converts text data suppUed by application 140 into an audio file. 
When discussing text-to-speech, Shank is referring to a high level function performed by 
the service, not an inter-object message format used for communicating with the service. 
Even if Shank's application 140 were to represent a manager object, which the applicants 
contend it does not, Shank still does not teach that apphcation 140 may choose text-to- 
speech as a format for message delivery when communicating with a service object. In 
fact, it is clear that when communicating with a text-to-speech service, one must provide 
the text to be converted into audio. Shank teaches that application 140 must use an 
interface specified bv the text-to-speech service's ORB vendor (Shank, column 3, line 
65-column 4, line 6). Thus, the text-to-speech service is not used to select a message 
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format for communicating between a manager and a managed object. Shank clearly does 
not describe a manager being able to select a format for message delivery that comprises 
text. Thus, in hght of the above remarks, apphcants assert that the rejection of claim 2 is 
not supported by the cited art and withdrawal of the rejection is respectfully requested. 
Similar remarks as discussed above in regard to claim 2 apply to claims 17 and 32. 

Li regard to claim 10, Shank does not teach that the gateway comprises a request 
gateway which is configured to deliver messages generated by the one or more managers 
to the one or more managed objects, wherein the messages comprises requests and 
wherein the requests comprise a query for information concerning one of the managed 
objects. The portions of Shank cited by the Examiner refer to application 140 invoking 
functions of the telephony and media services. These teachings have nothing to do with a 
query for information concerning a managed object. The concepts of managers and 
managed objects are well understood in the art of managed networks. Managers and 
managed objects have a well-known relationship in managed networks. Shank does not 
pertain to interactions between managers and managed objects, as these entities are 
understood in the art. In contrast, Shank only discusses the client-server interactions 
between application 140 and server 110. In other words, Shank only discusses providing 
telephony and media services through a server to a client application. Shank does not 
discuss managing managed network objects. Furthermore, nowhere does Shank teach a 
query for information concerning a managed object. 

In response to applicants' previous argument, the Examiner refers only to Shank's 
providing services through media, telephony and basic service interfaces, but the 
Examiner fails to point out anything regarding a query for information. The Examiner 
seems to have misunderstood applicants' previous argument. Applicants assert that 
Shank fails to teach wherein the messages comprise a query for information concerning 
one or more of the managed objects. Shank clearly fails to teach anything concerning 
such a query for information. Thus, in light of the above remarks, applicants assert that 
the rejection of claim 10 is not supported by the cited art and withdrawal of the rejection 
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is respectfully requested. Similar remarks as discussed above in regard to claim 10 apply 
to claims 25 and 40. 

Similarly, in regard to claim 11, Shank does not teach wherein the requests 
comprise a command to set one or more parameters of one of the managed objects . The 
Examiner cites a passage in Shank (column 17, lines 53-66), that describes parameters for 
a specific function (Play) of the Player media service interface, but does not mention a 
command to set parameters for a managed object. A parameter to a specific service 
method invocation is very different from a command to set one or more parameters of a 
managed object and Shank does not mention such a command, just that parameters may 
be used when invoking specific service method invocations. The Examiner has failed 
to provide any response to this specific argument in the Response to Arguments 
section of the Office Action. Thus, in light of the above remarks, applicants assert that 
the rejection of claim 11 is not supported by the cited art and withdrawal of the rejection 
is respectfully requested. Similar remarks as discussed above in regard to claim 1 1 apply 
to claims 26 and 41. 

In regard to claim 13, applicants disagree with the Examiner's contention that 
Shank teaches, "requests are converted from the interface definition language to a 
platform-specific format prior to delivery to the managed objects." The Examiner refers 
to col. 5, lines 39-50, of Shank, hi fact, Shank fails to teach that requests are converted 
from the interface definition language to a platform-specific format prior to delivery to 
the managed objects. The Examiner's cited portion of Shank discusses examples of 
media and telephony services but teaches nothing about converting requests from the 
interface definition language to a platform-specific format prior to delivery to the 
managed objects, hi fact, nowhere does Shank teach or even suggest that requests are 
converted. Thus, applicants can see no basis for the Examiner's contention regarding 
converting requests and submit that this is mere speculation on the Examiner's part. In 
response, the Examiner refers to Shank's teachings regarding the communication with 
different objects by different protocols "based on an industry standard" and further 
argues, "ASNl can be implemented in Shank's system." Applicants fail to find any 
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relevance to the Examiner's reference to ASNl . Shank does not mention ASNl at all and 
certainly does not teach or suggest the use of ASNl. Furthermore, even if ASNl were to 
be implemented in Shank's system, that would not require that Shank's system include 
the translation of request messages. The Examiner seems to be implying that it would be 
obvious to modify Shank's system to include the translation of request messages; 
however, a rejection based on such modification is clearly improper in a § 102(e) 
anticipation rejection. 

The Examiner further refers to Shank's teachings regarding "converting requests 
before delivering them to objects when the user and server [execute] in different 
process[es]" and cites column 4, lines 35-40 of Shank. However, this portion of Shank 
discusses the marshalling of a method invocation in order to communicate between a 
client in one process and a server in a different process. Marshalling of method 
invocations does not involve the translation of any request messages. Shank is not 
discussing translating of request messages at all, but rather Shank is discussing inter- 
process communication. 

Shank clearly does not anticipate wherein requests are converted from an 
interface definition language to a platform-specific format prior to delivery to the 
managed objects. Thus, in light of the above remarks, applicants assert that the rejection 
of claim 13 is not supported by the cited art and withdrawal of the rejection is 
respectfully requested. Similar remarks as discussed above in regard to claim 13 apply to 
claims 28 and 43. 

Section 103(a) Rejection : 

The Office Action rejected claims 3, 12, 18, 27, 33 and 42 under 35 U.S.C. § 
103(a) as being unpatentable over Shank, et al. (U.S. Patent 6,445,776) (hereinafter 
"Shank"). Applicants respectfully traverse this rejection in Ught of the following 
remarks. 
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Applicants submit that the Examiner has not estabUshed a proper prima facie case 
of obviousness in regard to these claims. Obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so in the prior art. In re 
Fine, 837 F.2d 1071 (Fed. Cir. 1988); M.P.E.P. § 2143.01. The question is whether 
there is something in the prior art as a whole to suggest the desirability, and thus the 
obviousness, of making the combination. Lindemann Maschinenfabrik GmbH v. 
American Hoist & Derrick Co., 221 USPQ 481, 488 (Fed. Cir. 1984). Merely stating that 
individual aspects of a claimed invention are well known does not render the combination 
well known without some objective reason to combine the individual teachings. Ex parte 
Levengood, 28 USPQ2d 1300. 

Furthermore, the Examiner's §103 (a) rejection amounts to nothing more than pure 
conclusory speculation by the Examiner. Mere speculation is not sufficient to support a 
prima facie case of obviousness. M.P.E.P. § 2142; see also. In re Warner, 379 F.2d 
1011, 1017, 154 USPQ 173, 178 (CCPA 1967); In re Sporck, 301 F.2d 686, 690, 133 
USPQ 360, 364 (CCPA 1962). "The factual inquiry whether to combine references must 
be thorough and searching." McGinley v. Franklin Sports, Inc., 60USPQ2d 1001, 1008 
(Fed. Cir. 2001). It must be based on objective evidence of record. "This precedent has 
been reinforced in myriad decisions, and cannot be dispensed with." In re Sang Su Lee, 
61 USPQ2d 1430 (Fed. Cir. 2002). "The need for specificity pervades this authority." Id. 
"Particular findings must be made as to the reason the skilled artisan, with no knowledge 
of the claimed invention, would have selected these components for combination in the 
manner claimed." In re Kotzab, 55 USPQ2d 1313, 1317 (Fed. Cir. 2000). 

For at least the reason stated above, applicants assert that the Examiner has not 
satisfied the rigorous tests for properly modifying a prior art reference to establish 
obviousness. Instead, as discussed above, the Examiner's reasoning is not supported by 
the teachings of the references, lacks specificity, and is based in hindsight. 
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Claims 3, 12, 18, 27, 33 and 42 are also distinguishable over the cited art for at 
least the reasons given above in regard to the individual claims from which they depend. 

Further regarding claim 3, Shank fails to teach wherein the selected format 
comprises Abstract Syntax Notation One (ASNl). The Examiner has not provided any 
prior art reference or specific finding that provides a motivation to use ASN.l in Shank in 
any way. The Examiner states only that such modifications would be obvious "for 
fulfilling the system requirements." However, there are no system requirements taught in 
Shank that would require or even suggest selecting ASN.l as a message format. The 
Examiner's stated motivation for modifying Shank ("fulfilling the system requirement") 
amounts to nothing more than an attempt to build the applicants invention through 
hindsight analysis and thus is clearly improper. 

Further regarding claim 12, Shank fails to disclose wherein the requests are 
converted from the interface definition language to a Portable Management Interface 
(PMI) format prior to delivery to the managed objects. The Examiner provided any prior 
art reference or specific finding that provides a motivation to modify Shank to convert 
requests from the interface definition language to a PMI format prior to delivery to the 
managed objects, as the Examiner contends. Nor is there any teaching in Shank that 
would require or even suggest converting requests from the interface definition language 
to a PMI format prior to dehvery to the managed objects. As with the rejection of claim 
3, discussed above. The Examiner's stated motivation for modifying Shank ("fulfilling 
the system requirement") amounts to nothing more than an attempt to build the applicants 
invention through hindsight analysis and is clearly improper. Additionally, Applicants' 
remarks above regarding the § 102(e) rejection of claim 13 apply here. 

In light of the above remarks, Applicants assert that the Examiner's rejections 
under § 103(a) are not supported by the cited art, and should thus be withdrawn. 

Applicants also assert that nimierous ones of the dependent claims recited further 
distinctions over the cited art. However, since the independent claims have been shown 
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to be patentably distinct, a further discussion of the dependent claims is not necessary at 
this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
61100/RCK. 

Also enclosed herewith are the following items: 
^ Return Receipt Postcard 
I I Petition for Extension of Time 
I I Notice of Change of Address 

I I Fee Authorization Form authorizing a deposit account debit in the amount of $ 
for fees ( ). 



Meyertons, Hood, IGvlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: November 4, 2004 
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□ Other: 



Respectfully submitted. 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



